home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 1999 November / SGI Freeware 1999 November - Disc 1.iso / dist / fw_cvs.idb / usr / freeware / info / cvs.info-3.z / cvs.info-3 (.txt)
GNU Info File  |  1999-04-16  |  51KB  |  998 lines
  1. This is Info file cvs.info, produced by Makeinfo version 1.67 from the
  2. input file ./cvs.texinfo.
  3. START-INFO-DIR-ENTRY
  4. * CVS: (cvs).          Concurrent Versions System
  5. END-INFO-DIR-ENTRY
  6.    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
  7. Free Software Foundation, Inc.
  8.    Permission is granted to make and distribute verbatim copies of this
  9. manual provided the copyright notice and this permission notice are
  10. preserved on all copies.
  11.    Permission is granted to copy and distribute modified versions of
  12. this manual under the conditions for verbatim copying, provided also
  13. that the entire resulting derived work is distributed under the terms
  14. of a permission notice identical to this one.
  15.    Permission is granted to copy and distribute translations of this
  16. manual into another language, under the above conditions for modified
  17. versions, except that this permission notice may be stated in a
  18. translation approved by the Free Software Foundation.
  19. File: cvs.info,  Node: Creating a branch,  Next: Accessing branches,  Prev: Branches motivation,  Up: Branching and merging
  20. Creating a branch
  21. =================
  22.    You can create a branch with `tag -b'; for example, assuming you're
  23. in a working copy:
  24.      $ cvs tag -b rel-1-0-patches
  25.    This splits off a branch based on the current revisions in the
  26. working copy, assigning that branch the name `rel-1-0-patches'.
  27.    It is important to understand that branches get created in the
  28. repository, not in the working copy.  Creating a branch based on
  29. current revisions, as the above example does, will *not* automatically
  30. switch the working copy to be on the new branch.  For information on how
  31. to do that, see *Note Accessing branches::.
  32.    You can also create a branch without reference to any working copy,
  33. by using `rtag':
  34.      $ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
  35.    `-r rel-1-0' says that this branch should be rooted at the revision
  36. that corresponds to the tag `rel-1-0'.  It need not be the most recent
  37. revision - it's often useful to split a branch off an old revision (for
  38. example, when fixing a bug in a past release otherwise known to be
  39. stable).
  40.    As with `tag', the `-b' flag tells `rtag' to create a branch (rather
  41. than just a symbolic revision name).  Note that the numeric revision
  42. number that matches `rel-1-0' will probably be different from file to
  43. file.
  44.    So, the full effect of the command is to create a new branch - named
  45. `rel-1-0-patches' - in module `tc', rooted in the revision tree at the
  46. point tagged by `rel-1-0'.
  47. File: cvs.info,  Node: Accessing branches,  Next: Branches and revisions,  Prev: Creating a branch,  Up: Branching and merging
  48. Accessing branches
  49. ==================
  50.    You can retrieve a branch in one of two ways: by checking it out
  51. fresh from the repository, or by switching an existing working copy
  52. over to the branch.
  53.    To check out a branch from the repository, invoke `checkout' with
  54. the `-r' flag, followed by the tag name of the branch (*note Creating a
  55. branch::.):
  56.      $ cvs checkout -r rel-1-0-patches tc
  57.    Or, if you already have a working copy, you can switch it to a given
  58. branch with `update -r':
  59.      $ cvs update -r rel-1-0-patches tc
  60.    or equivalently:
  61.      $ cd tc
  62.      $ cvs update -r rel-1-0-patches
  63.    It does not matter if the working copy was originally on the main
  64. trunk or on some other branch - the above command will switch it to the
  65. named branch.  And similarly to a regular `update' command, `update -r'
  66. merges any changes you have made, notifying you of conflicts where they
  67. occur.
  68.    Once you have a working copy tied to a particular branch, it remains
  69. there until you tell it otherwise.  This means that changes checked in
  70. from the working copy will add new revisions on that branch, while
  71. leaving the main trunk and other branches unaffected.
  72.    To find out what branch a working copy is on, you can use the
  73. `status' command.  In its output, look for the field named `Sticky tag'
  74. (*note Sticky tags::.) - that's CVS's way of telling you the branch, if
  75. any, of the current working files:
  76.      $ cvs status -v driver.c backend.c
  77.      ===================================================================
  78.      File: driver.c          Status: Up-to-date
  79.      
  80.          Version:            1.7     Sat Dec  5 18:25:54 1992
  81.          RCS Version:        1.7     /u/cvsroot/yoyodyne/tc/driver.c,v
  82.          Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
  83.          Sticky Date:        (none)
  84.          Sticky Options:     (none)
  85.      
  86.          Existing Tags:
  87.              rel-1-0-patches             (branch: 1.7.2)
  88.              rel-1-0                     (revision: 1.7)
  89.      
  90.      ===================================================================
  91.      File: backend.c         Status: Up-to-date
  92.      
  93.          Version:            1.4     Tue Dec  1 14:39:01 1992
  94.          RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
  95.          Sticky Tag:         rel-1-0-patches (branch: 1.4.2)
  96.          Sticky Date:        (none)
  97.          Sticky Options:     (none)
  98.      
  99.          Existing Tags:
  100.              rel-1-0-patches             (branch: 1.4.2)
  101.              rel-1-0                     (revision: 1.4)
  102.              rel-0-4                     (revision: 1.4)
  103.    Don't be confused by the fact that the branch numbers for each file
  104. are different (`1.7.2' and `1.4.2' respectively).  The branch tag is the
  105. same, `rel-1-0-patches', and the files are indeed on the same branch.
  106. The numbers simply reflect the point in each file's revision history at
  107. which the branch was made.  In the above example, one can deduce that
  108. `driver.c' had been through more changes than `backend.c' before this
  109. branch was created.
  110.    See *Note Branches and revisions:: for details about how branch
  111. numbers are constructed.
  112. File: cvs.info,  Node: Branches and revisions,  Next: Magic branch numbers,  Prev: Accessing branches,  Up: Branching and merging
  113. Branches and revisions
  114. ======================
  115.    Ordinarily, a file's revision history is a linear series of
  116. increments (*note Revision numbers::.):
  117.             +-----+    +-----+    +-----+    +-----+    +-----+
  118.             ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
  119.             +-----+    +-----+    +-----+    +-----+    +-----+
  120.    However, CVS is not limited to linear development.  The "revision
  121. tree" can be split into "branches", where each branch is a
  122. self-maintained line of development.  Changes made on one branch can
  123. easily be moved back to the main trunk.
  124.    Each branch has a "branch number", consisting of an odd number of
  125. period-separated decimal integers.  The branch number is created by
  126. appending an integer to the revision number where the corresponding
  127. branch forked off.  Having branch numbers allows more than one branch
  128. to be forked off from a certain revision.
  129.    All revisions on a branch have revision numbers formed by appending
  130. an ordinal number to the branch number.  The following figure
  131. illustrates branching with an example.
  132.                                            +-------------+
  133.                 Branch 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
  134.                                          / +-------------+
  135.                                         /
  136.                                        /
  137.                       +---------+    +---------+    +---------+
  138.      Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
  139.                     / +---------+    +---------+    +---------+
  140.                    /
  141.                   /
  142.      +-----+    +-----+    +-----+    +-----+    +-----+
  143.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !  <- The main trunk
  144.      +-----+    +-----+    +-----+    +-----+    +-----+
  145.                      !
  146.                      !
  147.                      !   +---------+    +---------+    +---------+
  148.      Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
  149.                          +---------+    +---------+    +---------+
  150.    The exact details of how the branch number is constructed is not
  151. something you normally need to be concerned about, but here is how it
  152. works: When CVS creates a branch number it picks the first unused even
  153. integer, starting with 2.  So when you want to create a branch from
  154. revision 6.4 it will be numbered 6.4.2.  All branch numbers ending in a
  155. zero (such as 6.4.0) are used internally by CVS (*note Magic branch
  156. numbers::.).  The branch 1.1.1 has a special meaning.  *Note Tracking
  157. sources::.
  158. File: cvs.info,  Node: Magic branch numbers,  Next: Merging a branch,  Prev: Branches and revisions,  Up: Branching and merging
  159. Magic branch numbers
  160. ====================
  161.    This section describes a CVS feature called "magic branches".  For
  162. most purposes, you need not worry about magic branches; CVS handles
  163. them for you.  However, they are visible to you in certain
  164. circumstances, so it may be useful to have some idea of how it works.
  165.    Externally, branch numbers consist of an odd number of dot-separated
  166. decimal integers.  *Note Revision numbers::.  That is not the whole
  167. truth, however.  For efficiency reasons CVS sometimes inserts an extra 0
  168. in the second rightmost position (1.2.4 becomes 1.2.0.4, 8.9.10.11.12
  169. becomes 8.9.10.11.0.12 and so on).
  170.    CVS does a pretty good job at hiding these so called magic branches,
  171. but in a few places the hiding is incomplete:
  172.    * The magic branch number appears in the output from `cvs log'.
  173.    * You cannot specify a symbolic branch name to `cvs admin'.
  174.    You can use the `admin' command to reassign a symbolic name to a
  175. branch the way RCS expects it to be.  If `R4patches' is assigned to the
  176. branch 1.4.2 (magic branch number 1.4.0.2) in file `numbers.c' you can
  177. do this:
  178.      $ cvs admin -NR4patches:1.4.2 numbers.c
  179.    It only works if at least one revision is already committed on the
  180. branch.  Be very careful so that you do not assign the tag to the wrong
  181. number.  (There is no way to see how the tag was assigned yesterday).
  182. File: cvs.info,  Node: Merging a branch,  Next: Merging more than once,  Prev: Magic branch numbers,  Up: Branching and merging
  183. Merging an entire branch
  184. ========================
  185.    You can merge changes made on a branch into your working copy by
  186. giving the `-j BRANCH' flag to the `update' command.  With one `-j
  187. BRANCH' option it merges the changes made between the point where the
  188. branch forked and newest revision on that branch (into your working
  189. copy).
  190.    The `-j' stands for "join".
  191.    Consider this revision tree:
  192.      +-----+    +-----+    +-----+    +-----+
  193.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
  194.      +-----+    +-----+    +-----+    +-----+
  195.                      !
  196.                      !
  197.                      !   +---------+    +---------+
  198.      Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
  199.                          +---------+    +---------+
  200. The branch 1.2.2 has been given the tag (symbolic name) `R1fix'.  The
  201. following example assumes that the module `mod' contains only one file,
  202. `m.c'.
  203.      $ cvs checkout mod               # Retrieve the latest revision, 1.4
  204.      
  205.      $ cvs update -j R1fix m.c        # Merge all changes made on the branch,
  206.                                       # i.e. the changes between revision 1.2
  207.                                       # and 1.2.2.2, into your working copy
  208.                                       # of the file.
  209.      
  210.      $ cvs commit -m "Included R1fix" # Create revision 1.5.
  211.    A conflict can result from a merge operation.  If that happens, you
  212. should resolve it before committing the new revision.  *Note Conflicts
  213. example::.
  214.    The `checkout' command also supports the `-j BRANCH' flag.  The same
  215. effect as above could be achieved with this:
  216.      $ cvs checkout -j R1fix mod
  217.      $ cvs commit -m "Included R1fix"
  218. File: cvs.info,  Node: Merging more than once,  Next: Merging two revisions,  Prev: Merging a branch,  Up: Branching and merging
  219. Merging from a branch several times
  220. ===================================
  221.    Continuing our example, the revision tree now looks like this:
  222.      +-----+    +-----+    +-----+    +-----+    +-----+
  223.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
  224.      +-----+    +-----+    +-----+    +-----+    +-----+
  225.                      !                           *
  226.                      !                          *
  227.                      !   +---------+    +---------+
  228.      Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
  229.                          +---------+    +---------+
  230.    where the starred line represents the merge from the `R1fix' branch
  231. to the main trunk, as just discussed.
  232.    Now suppose that development continues on the `R1fix' branch:
  233.      +-----+    +-----+    +-----+    +-----+    +-----+
  234.      ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
  235.      +-----+    +-----+    +-----+    +-----+    +-----+
  236.                      !                           *
  237.                      !                          *
  238.                      !   +---------+    +---------+    +---------+
  239.      Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
  240.                          +---------+    +---------+    +---------+
  241.    and then you want to merge those new changes onto the main trunk.
  242. If you just use the `cvs update -j R1fix m.c' command again, CVS will
  243. attempt to merge again the changes which you have already merged, which
  244. can have undesirable side effects.
  245.    So instead you need to specify that you only want to merge the
  246. changes on the branch which have not yet been merged into the trunk.
  247. To do that you specify two `-j' options, and CVS merges the changes from
  248. the first revision to the second revision.  For example, in this case
  249. the simplest way would be
  250.      cvs update -j 1.2.2.2 -j R1fix m.c    # Merge changes from 1.2.2.2 to the
  251.                                            # head of the R1fix branch
  252.    The problem with this is that you need to specify the 1.2.2.2
  253. revision manually.  A slightly better approach might be to use the date
  254. the last merge was done:
  255.      cvs update -j R1fix:yesterday -j R1fix m.c
  256.    Better yet, tag the R1fix branch after every merge into the trunk,
  257. and then use that tag for subsequent merges:
  258.      cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
  259. File: cvs.info,  Node: Merging two revisions,  Next: Merging adds and removals,  Prev: Merging more than once,  Up: Branching and merging
  260. Merging differences between any two revisions
  261. =============================================
  262.    With two `-j REVISION' flags, the `update' (and `checkout') command
  263. can merge the differences between any two revisions into your working
  264. file.
  265.      $ cvs update -j 1.5 -j 1.3 backend.c
  266. will *remove* all changes made between revision 1.3 and 1.5.  Note the
  267. order of the revisions!
  268.    If you try to use this option when operating on multiple files,
  269. remember that the numeric revisions will probably be very different
  270. between the various files that make up a module.  You almost always use
  271. symbolic tags rather than revision numbers when operating on multiple
  272. files.
  273. File: cvs.info,  Node: Merging adds and removals,  Prev: Merging two revisions,  Up: Branching and merging
  274. Merging can add or remove files
  275. ===============================
  276.    If the changes which you are merging involve removing or adding some
  277. files, `update -j' will reflect such additions or removals.
  278.    For example:
  279.      cvs update -A
  280.      touch a b c
  281.      cvs add a b c ; cvs ci -m "added" a b c
  282.      cvs tag -b branchtag
  283.      cvs update -r branchtag
  284.      touch d ; cvs add d
  285.      rm a ; cvs rm a
  286.      cvs ci -m "added d, removed a"
  287.      cvs update -A
  288.      cvs update -jbranchtag
  289.    After these commands are executed and a `cvs commit' is done, file
  290. `a' will be removed and file `d' added in the main branch.
  291. File: cvs.info,  Node: Recursive behavior,  Next: Adding and removing,  Prev: Branching and merging,  Up: Top
  292. Recursive behavior
  293. ******************
  294.    Almost all of the subcommands of CVS work recursively when you
  295. specify a directory as an argument.  For instance, consider this
  296. directory structure:
  297.            `$HOME'
  298.              |
  299.              +--tc
  300.              |   |
  301.                  +--CVS
  302.                  |      (internal CVS files)
  303.                  +--Makefile
  304.                  +--backend.c
  305.                  +--driver.c
  306.                  +--frontend.c
  307.                  +--parser.c
  308.                  +--man
  309.                  |    |
  310.                  |    +--CVS
  311.                  |    |  (internal CVS files)
  312.                  |    +--tc.1
  313.                  |
  314.                  +--testing
  315.                       |
  316.                       +--CVS
  317.                       |  (internal CVS files)
  318.                       +--testpgm.t
  319.                       +--test2.t
  320. If `tc' is the current working directory, the following is true:
  321.    * `cvs update testing' is equivalent to
  322.           cvs update testing/testpgm.t testing/test2.t
  323.    * `cvs update testing man' updates all files in the subdirectories
  324.    * `cvs update .' or just `cvs update' updates all files in the `tc'
  325.      module
  326.    If no arguments are given to `update' it will update all files in
  327. the current working directory and all its subdirectories.  In other
  328. words, `.' is a default argument to `update'.  This is also true for
  329. most of the CVS subcommands, not only the `update' command.
  330.    The recursive behavior of the CVS subcommands can be turned off with
  331. the `-l' option.  Conversely, the `-R' option can be used to force
  332. recursion if `-l' is specified in `~/.cvsrc' (*note ~/.cvsrc::.).
  333.      $ cvs update -l         # Don't update files in subdirectories
  334. File: cvs.info,  Node: Adding and removing,  Next: History browsing,  Prev: Recursive behavior,  Up: Top
  335. Adding, removing, and renaming files and directories
  336. ****************************************************
  337.    In the course of a project, one will often add new files.  Likewise
  338. with removing or renaming, or with directories.  The general concept to
  339. keep in mind in all these cases is that instead of making an
  340. irreversible change you want CVS to record the fact that a change has
  341. taken place, just as with modifying an existing file.  The exact
  342. mechanisms to do this in CVS vary depending on the situation.
  343. * Menu:
  344. * Adding files::                Adding files
  345. * Removing files::              Removing files
  346. * Removing directories::        Removing directories
  347. * Moving files::                Moving and renaming files
  348. * Moving directories::          Moving and renaming directories
  349. File: cvs.info,  Node: Adding files,  Next: Removing files,  Up: Adding and removing
  350. Adding files to a directory
  351. ===========================
  352.    To add a new file to a directory, follow these steps.
  353.    * You must have a working copy of the directory.  *Note Getting the
  354.      source::.
  355.    * Create the new file inside your working copy of the directory.
  356.    * Use `cvs add FILENAME' to tell CVS that you want to version
  357.      control the file.  If the file contains binary data, specify `-kb'
  358.      (*note Binary files::.).
  359.    * Use `cvs commit FILENAME' to actually check in the file into the
  360.      repository.  Other developers cannot see the file until you
  361.      perform this step.
  362.    You can also use the `add' command to add a new directory.
  363.    Unlike most other commands, the `add' command is not recursive.  You
  364. cannot even type `cvs add foo/bar'!  Instead, you have to
  365.      $ cd foo
  366.      $ cvs add bar
  367.  - Command: cvs add [`-k' KFLAG] [`-m' MESSAGE] FILES ...
  368.      Schedule FILES to be added to the repository.  The files or
  369.      directories specified with `add' must already exist in the current
  370.      directory.  To add a whole new directory hierarchy to the source
  371.      repository (for example, files received from a third-party
  372.      vendor), use the `import' command instead.  *Note import::.
  373.      The added files are not placed in the source repository until you
  374.      use `commit' to make the change permanent.  Doing an `add' on a
  375.      file that was removed with the `remove' command will undo the
  376.      effect of the `remove', unless a `commit' command intervened.
  377.      *Note Removing files::, for an example.
  378.      The `-k' option specifies the default way that this file will be
  379.      checked out; for more information see *Note Substitution modes::.
  380.      The `-m' option specifies a description for the file.  This
  381.      description appears in the history log (if it is enabled, *note
  382.      history file::.).  It will also be saved in the version history
  383.      inside the repository when the file is committed.  The `log'
  384.      command displays this description.  The description can be changed
  385.      using `admin -t'.  *Note admin::.  If you omit the `-m
  386.      DESCRIPTION' flag, an empty string will be used.  You will not be
  387.      prompted for a description.
  388.    For example, the following commands add the file `backend.c' to the
  389. repository:
  390.      $ cvs add backend.c
  391.      $ cvs commit -m "Early version. Not yet compilable." backend.c
  392.    When you add a file it is added only on the branch which you are
  393. working on (*note Branching and merging::.).  You can later merge the
  394. additions to another branch if you want (*note Merging adds and
  395. removals::.).
  396. File: cvs.info,  Node: Removing files,  Next: Removing directories,  Prev: Adding files,  Up: Adding and removing
  397. Removing files
  398. ==============
  399.    Modules change.  New files are added, and old files disappear.
  400. Still, you want to be able to retrieve an exact copy of old releases.
  401.    Here is what you can do to remove a file, but remain able to
  402. retrieve old revisions:
  403.    * Make sure that you have not made any uncommitted modifications to
  404.      the file.  *Note Viewing differences::, for one way to do that.
  405.      You can also use the `status' or `update' command.  If you remove
  406.      the file without committing your changes, you will of course not
  407.      be able to retrieve the file as it was immediately before you
  408.      deleted it.
  409.    * Remove the file from your working copy of the directory.  You can
  410.      for instance use `rm'.
  411.    * Use `cvs remove FILENAME' to tell CVS that you really want to
  412.      delete the file.
  413.    * Use `cvs commit FILENAME' to actually perform the removal of the
  414.      file from the repository.
  415.    When you commit the removal of the file, CVS records the fact that
  416. the file no longer exists.  It is possible for a file to exist on only
  417. some branches and not on others, or to re-add another file with the same
  418. name later.  CVS will correctly create or not create the file, based on
  419. the `-r' and `-D' options specified to `checkout' or `update'.
  420.  - Command: cvs remove [OPTIONS] FILES ...
  421.      Schedule file(s) to be removed from the repository (files which
  422.      have not already been removed from the working directory are not
  423.      processed).  This command does not actually remove the file from
  424.      the repository until you commit the removal.  For a full list of
  425.      options, see *Note Invoking CVS::.
  426.    Here is an example of removing several files:
  427.      $ cd test
  428.      $ rm *.c
  429.      $ cvs remove
  430.      cvs remove: Removing .
  431.      cvs remove: scheduling a.c for removal
  432.      cvs remove: scheduling b.c for removal
  433.      cvs remove: use 'cvs commit' to remove these files permanently
  434.      $ cvs ci -m "Removed unneeded files"
  435.      cvs commit: Examining .
  436.      cvs commit: Committing .
  437.    As a convenience you can remove the file and `cvs remove' it in one
  438. step, by specifying the `-f' option.  For example, the above example
  439. could also be done like this:
  440.      $ cd test
  441.      $ cvs remove -f *.c
  442.      cvs remove: scheduling a.c for removal
  443.      cvs remove: scheduling b.c for removal
  444.      cvs remove: use 'cvs commit' to remove these files permanently
  445.      $ cvs ci -m "Removed unneeded files"
  446.      cvs commit: Examining .
  447.      cvs commit: Committing .
  448.    If you execute `remove' for a file, and then change your mind before
  449. you commit, you can undo the `remove' with an `add' command.
  450.      $ ls
  451.      CVS   ja.h  oj.c
  452.      $ rm oj.c
  453.      $ cvs remove oj.c
  454.      cvs remove: scheduling oj.c for removal
  455.      cvs remove: use 'cvs commit' to remove this file permanently
  456.      $ cvs add oj.c
  457.      U oj.c
  458.      cvs add: oj.c, version 1.1.1.1, resurrected
  459.    If you realize your mistake before you run the `remove' command you
  460. can use `update' to resurrect the file:
  461.      $ rm oj.c
  462.      $ cvs update oj.c
  463.      cvs update: warning: oj.c was lost
  464.      U oj.c
  465.    When you remove a file it is removed only on the branch which you
  466. are working on (*note Branching and merging::.).  You can later merge
  467. the removals to another branch if you want (*note Merging adds and
  468. removals::.).
  469. File: cvs.info,  Node: Removing directories,  Next: Moving files,  Prev: Removing files,  Up: Adding and removing
  470. Removing directories
  471. ====================
  472.    In concept removing directories is somewhat similar to removing
  473. files--you want the directory to not exist in your current working
  474. directories, but you also want to be able to retrieve old releases in
  475. which the directory existed.
  476.    The way that you remove a directory is to remove all the files in
  477. it.  You don't remove the directory itself; there is no way to do that.
  478. Instead you specify the `-P' option to `cvs update', `cvs checkout', or
  479. `cvs export', which will cause CVS to remove empty directories from
  480. working directories.  Probably the best way to do this is to always
  481. specify `-P'; if you want an empty directory then put a dummy file (for
  482. example `.keepme') in it to prevent `-P' from removing it.
  483.    Note that `-P' is implied by the `-r' or `-D' options of `checkout'
  484. and `export'.  This way CVS will be able to correctly create the
  485. directory or not depending on whether the particular version you are
  486. checking out contains any files in that directory.
  487. File: cvs.info,  Node: Moving files,  Next: Moving directories,  Prev: Removing directories,  Up: Adding and removing
  488. Moving and renaming files
  489. =========================
  490.    Moving files to a different directory or renaming them is not
  491. difficult, but some of the ways in which this works may be non-obvious.
  492. (Moving or renaming a directory is even harder.  *Note Moving
  493. directories::.).
  494.    The examples below assume that the file OLD is renamed to NEW.
  495. * Menu:
  496. * Outside::                     The normal way to Rename
  497. * Inside::                      A tricky, alternative way
  498. * Rename by copying::           Another tricky, alternative way
  499. File: cvs.info,  Node: Outside,  Next: Inside,  Up: Moving files
  500. The Normal way to Rename
  501. ------------------------
  502.    The normal way to move a file is to copy OLD to NEW, and then issue
  503. the normal CVS commands to remove OLD from the repository, and add NEW
  504. to it.
  505.      $ mv OLD NEW
  506.      $ cvs remove OLD
  507.      $ cvs add NEW
  508.      $ cvs commit -m "Renamed OLD to NEW" OLD NEW
  509.    This is the simplest way to move a file, it is not error-prone, and
  510. it preserves the history of what was done.  Note that to access the
  511. history of the file you must specify the old or the new name, depending
  512. on what portion of the history you are accessing.  For example, `cvs
  513. log OLD' will give the log up until the time of the rename.
  514.    When NEW is committed its revision numbers will start again, usually
  515. at 1.1, so if that bothers you, use the `-r rev' option to commit.  For
  516. more information see *Note Assigning revisions::.
  517. File: cvs.info,  Node: Inside,  Next: Rename by copying,  Prev: Outside,  Up: Moving files
  518. Moving the history file
  519. -----------------------
  520.    This method is more dangerous, since it involves moving files inside
  521. the repository.  Read this entire section before trying it out!
  522.      $ cd $CVSROOT/MODULE
  523.      $ mv OLD,v NEW,v
  524. Advantages:
  525.    * The log of changes is maintained intact.
  526.    * The revision numbers are not affected.
  527. Disadvantages:
  528.    * Old releases of the module cannot easily be fetched from the
  529.      repository.  (The file will show up as NEW even in revisions from
  530.      the time before it was renamed).
  531.    * There is no log information of when the file was renamed.
  532.    * Nasty things might happen if someone accesses the history file
  533.      while you are moving it.  Make sure no one else runs any of the CVS
  534.      commands while you move it.
  535. File: cvs.info,  Node: Rename by copying,  Prev: Inside,  Up: Moving files
  536. Copying the history file
  537. ------------------------
  538.    This way also involves direct modifications to the repository.  It
  539. is safe, but not without drawbacks.
  540.      # Copy the RCS file inside the repository
  541.      $ cd $CVSROOT/MODULE
  542.      $ cp OLD,v NEW,v
  543.      # Remove the old file
  544.      $ cd ~/MODULE
  545.      $ rm OLD
  546.      $ cvs remove OLD
  547.      $ cvs commit OLD
  548.      # Remove all tags from NEW
  549.      $ cvs update NEW
  550.      $ cvs log NEW             # Remember the non-branch tag names
  551.      $ cvs tag -d TAG1 NEW
  552.      $ cvs tag -d TAG2 NEW
  553.      ...
  554.    By removing the tags you will be able to check out old revisions of
  555. the module.
  556. Advantages:
  557.    * Checking out old revisions works correctly, as long as you use
  558.      `-rTAG' and not `-DDATE' to retrieve the revisions.
  559.    * The log of changes is maintained intact.
  560.    * The revision numbers are not affected.
  561. Disadvantages:
  562.    * You cannot easily see the history of the file across the rename.
  563. File: cvs.info,  Node: Moving directories,  Prev: Moving files,  Up: Adding and removing
  564. Moving and renaming directories
  565. ===============================
  566.    The normal way to rename or move a directory is to rename or move
  567. each file within it as described in *Note Outside::.  Then check out
  568. with the `-P' option, as described in *Note Removing directories::.
  569.    If you really want to hack the repository to rename or delete a
  570. directory in the repository, you can do it like this:
  571.   1. Inform everyone who has a copy of the module that the directory
  572.      will be renamed.  They should commit all their changes, and remove
  573.      their working copies of the module, before you take the steps
  574.      below.
  575.   2. Rename the directory inside the repository.
  576.           $ cd $CVSROOT/MODULE
  577.           $ mv OLD-DIR NEW-DIR
  578.   3. Fix the CVS administrative files, if necessary (for instance if
  579.      you renamed an entire module).
  580.   4. Tell everyone that they can check out the module and continue
  581.      working.
  582.    If someone had a working copy of the module the CVS commands will
  583. cease to work for him, until he removes the directory that disappeared
  584. inside the repository.
  585.    It is almost always better to move the files in the directory
  586. instead of moving the directory.  If you move the directory you are
  587. unlikely to be able to retrieve old releases correctly, since they
  588. probably depend on the name of the directories.
  589. File: cvs.info,  Node: History browsing,  Next: Binary files,  Prev: Adding and removing,  Up: Top
  590. History browsing
  591. ****************
  592.    Once you have used CVS to store a version control history--what
  593. files have changed when, how, and by whom, there are a variety of
  594. mechanisms for looking through the history.
  595. * Menu:
  596. * log messages::                Log messages
  597. * history database::            The history database
  598. * user-defined logging::        User-defined logging
  599. * annotate::                    What revision modified each line of a file?
  600. File: cvs.info,  Node: log messages,  Next: history database,  Up: History browsing
  601. Log messages
  602. ============
  603.    Whenever you commit a file you specify a log message.
  604.    To look through the log messages which have been specified for every
  605. revision which has been committed, use the `cvs log' command (*note
  606. log::.).
  607. File: cvs.info,  Node: history database,  Next: user-defined logging,  Prev: log messages,  Up: History browsing
  608. The history database
  609. ====================
  610.    You can use the history file (*note history file::.) to log various
  611. CVS actions.  To retrieve the information from the history file, use
  612. the `cvs history' command (*note history::.).
  613. File: cvs.info,  Node: user-defined logging,  Next: annotate,  Prev: history database,  Up: History browsing
  614. User-defined logging
  615. ====================
  616.    You can customize CVS to log various kinds of actions, in whatever
  617. manner you choose.  These mechanisms operate by executing a script at
  618. various times.  The script might append a message to a file listing the
  619. information and the programmer who created it, or send mail to a group
  620. of developers, or, perhaps, post a message to a particular newsgroup.
  621. To log commits, use the `loginfo' file (*note loginfo::.).  To log
  622. commits, checkouts, exports, and tags, respectively, you can also use
  623. the `-i', `-o', `-e', and `-t' options in the modules file.  For a more
  624. flexible way of giving notifications to various users, which requires
  625. less in the way of keeping centralized scripts up to date, use the `cvs
  626. watch add' command (*note Getting Notified::.); this command is useful
  627. even if you are not using `cvs watch on'.
  628.    The `taginfo' file defines programs to execute when someone executes
  629. a `tag' or `rtag' command.  The `taginfo' file has the standard form
  630. for administrative files (*note Administrative files::.), where each
  631. line is a regular expression followed by a command to execute.  The
  632. arguments passed to the command are, in order, the TAGNAME, OPERATION
  633. (`add' for `tag', `mov' for `tag -F', and `del' for `tag -d'),
  634. REPOSITORY, and any remaining are pairs of FILENAME REVISION.  A
  635. non-zero exit of the filter program will cause the tag to be aborted.
  636.    Here is an example of using taginfo to log tag and rtag commands.
  637. In the taginfo file put:
  638.      ALL /usr/local/cvsroot/CVSROOT/loggit
  639.    Where `/usr/local/cvsroot/CVSROOT/loggit' contains the following
  640. script:
  641.      #!/bin/sh
  642.      echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog
  643. File: cvs.info,  Node: annotate,  Prev: user-defined logging,  Up: History browsing
  644. Annotate command
  645. ================
  646.  - Command: cvs annotate [`-flR'] [`-r rev'|`-D date'] FILES ...
  647.      For each file in FILES, print the head revision of the trunk,
  648.      together with information on the last modification for each line.
  649.      For example:
  650.           $ cvs annotate ssfile
  651.           Annotations for ssfile
  652.           ***************
  653.           1.1          (mary     27-Mar-96): ssfile line 1
  654.           1.2          (joe      28-Mar-96): ssfile line 2
  655.      The file `ssfile' currently contains two lines.  The `ssfile line
  656.      1' line was checked in by `mary' on March 27.  Then, on March 28,
  657.      `joe' added a line `ssfile line 2', without modifying the `ssfile
  658.      line 1' line.  This report doesn't tell you anything about lines
  659.      which have been deleted or replaced; you need to use `cvs diff'
  660.      for that (*note diff::.).
  661.    The options to `cvs annotate' are listed in *Note Invoking CVS::,
  662. and can be used to select the files and revisions to annotate.  The
  663. options are described in more detail in *Note Common options::.
  664. File: cvs.info,  Node: Binary files,  Next: Multiple developers,  Prev: History browsing,  Up: Top
  665. Handling binary files
  666. *********************
  667.    The most common use for CVS is to store text files.  With text
  668. files, CVS can merge revisions, display the differences between
  669. revisions in a human-visible fashion, and other such operations.
  670. However, if you are willing to give up a few of these abilities, CVS
  671. can store binary files.  For example, one might store a web site in CVS
  672. including both text files and binary images.
  673. * Menu:
  674. * Binary why::     More details on issues with binary files
  675. * Binary howto::   How to store them
  676. File: cvs.info,  Node: Binary why,  Next: Binary howto,  Up: Binary files
  677. The issues with binary files
  678. ============================
  679.    While the need to manage binary files may seem obvious if the files
  680. that you customarily work with are binary, putting them into version
  681. control does present some additional issues.
  682.    One basic function of version control is to show the differences
  683. between two revisions.  For example, if someone else checked in a new
  684. version of a file, you may wish to look at what they changed and
  685. determine whether their changes are good.  For text files, CVS provides
  686. this functionality via the `cvs diff' command.  For binary files, it
  687. may be possible to extract the two revisions and then compare them with
  688. a tool external to CVS (for example, word processing software often has
  689. such a feature).  If there is no such tool, one must track changes via
  690. other mechanisms, such as urging people to write good log messages, and
  691. hoping that the changes they actually made were the changes that they
  692. intended to make.
  693.    Another ability of a version control system is the ability to merge
  694. two revisions.  For CVS this happens in two contexts.  The first is
  695. when users make changes in separate working directories (*note Multiple
  696. developers::.).  The second is when one merges explicitly with the
  697. `update -j' command (*note Branching and merging::.).
  698.    In the case of text files, CVS can merge changes made independently,
  699. and signal a conflict if the changes conflict.  With binary files, the
  700. best that CVS can do is present the two different copies of the file,
  701. and leave it to the user to resolve the conflict.  The user may choose
  702. one copy or the other, or may run an external merge tool which knows
  703. about that particular file format, if one exists.  Note that having the
  704. user merge relies primarily on the user to not accidentally omit some
  705. changes, and thus is potentially error prone.
  706.    If this process is thought to be undesirable, the best choice may be
  707. to avoid merging.  To avoid the merges that result from separate
  708. working directories, see the discussion of reserved checkouts (file
  709. locking) in *Note Multiple developers::.  To avoid the merges resulting
  710. from branches, restrict use of branches.
  711. File: cvs.info,  Node: Binary howto,  Prev: Binary why,  Up: Binary files
  712. How to store binary files
  713. =========================
  714.    There are two issues with using CVS to store binary files.  The
  715. first is that CVS by default converts line endings between the
  716. canonical form in which they are stored in the repository (linefeed
  717. only), and the form appropriate to the operating system in use on the
  718. client (for example, carriage return followed by line feed for Windows
  719.    The second is that a binary file might happen to contain data which
  720. looks like a keyword (*note Keyword substitution::.), so keyword
  721. expansion must be turned off.
  722.    The `-kb' option available with some CVS commands insures that
  723. neither line ending conversion nor keyword expansion will be done.
  724.    Here is an example of how you can create a new file using the `-kb'
  725. flag:
  726.      $ echo '$Id$' > kotest
  727.      $ cvs add -kb -m"A test file" kotest
  728.      $ cvs ci -m"First checkin; contains a keyword" kotest
  729.    If a file accidentally gets added without `-kb', one can use the
  730. `cvs admin' command to recover.  For example:
  731.      $ echo '$Id$' > kotest
  732.      $ cvs add -m"A test file" kotest
  733.      $ cvs ci -m"First checkin; contains a keyword" kotest
  734.      $ cvs admin -kb kotest
  735.      $ cvs update -A kotest
  736.      # For non-unix systems:
  737.      # Copy in a good copy of the file from outside CVS
  738.      $ cvs commit -m "make it binary" kotest
  739.    When you check in the file `kotest' the file is not preserved as a
  740. binary file, because you did not check it in as a binary file.  The `cvs
  741. admin -kb' command sets the default keyword substitution method for
  742. this file, but it does not alter the working copy of the file that you
  743. have.  If you need to cope with line endings (that is, you are using
  744. CVS on a non-unix system), then you need to check in a new copy of the
  745. file, as shown by the `cvs commit' command above.  On unix, the `cvs
  746. update -A' command suffices.
  747.    However, in using `cvs admin -k' to change the keyword expansion, be
  748. aware that the keyword expansion mode is not version controlled.  This
  749. means that, for example, that if you have a text file in old releases,
  750. and a binary file with the same name in new releases, CVS provides no
  751. way to check out the file in text or binary mode depending on what
  752. version you are checking out.  There is no good workaround for this
  753. problem.
  754.    You can also set a default for whether `cvs add' and `cvs import'
  755. treat a file as binary based on its name; for example you could say
  756. that files who names end in `.exe' are binary.  *Note Wrappers::.
  757. There is currently no way to have CVS detect whether a file is binary
  758. based on its contents.  The main difficulty with designing such a
  759. feature is that it is not clear how to distinguish between binary and
  760. non-binary files, and the rules to apply would vary considerably with
  761. the operating system.
  762. File: cvs.info,  Node: Multiple developers,  Next: Revision management,  Prev: Binary files,  Up: Top
  763. Multiple developers
  764. *******************
  765.    When more than one person works on a software project things often
  766. get complicated.  Often, two people try to edit the same file
  767. simultaneously.  One solution, known as "file locking" or "reserved
  768. checkouts", is to allow only one person to edit each file at a time.
  769. This is the only solution with some version control systems, including
  770. RCS and SCCS.  Currently the usual way to get reserved checkouts with
  771. CVS is the `cvs admin -l' command (*note admin options::.).  This is
  772. not as nicely integrated into CVS as the watch features, described
  773. below, but it seems that most people with a need for reserved checkouts
  774. find it adequate.  It also may be possible to use the watches features
  775. described below, together with suitable procedures (not enforced by
  776. software), to avoid having two people edit at the same time.
  777.    The default model with CVS is known as "unreserved checkouts".  In
  778. this model, developers can edit their own "working copy" of a file
  779. simultaneously.  The first person that commits his changes has no
  780. automatic way of knowing that another has started to edit it.  Others
  781. will get an error message when they try to commit the file.  They must
  782. then use CVS commands to bring their working copy up to date with the
  783. repository revision.  This process is almost automatic.
  784.    CVS also supports mechanisms which facilitate various kinds of
  785. communcation, without actually enforcing rules like reserved checkouts
  786.    The rest of this chapter describes how these various models work,
  787. and some of the issues involved in choosing between them.
  788. * Menu:
  789. * File status::                 A file can be in several states
  790. * Updating a file::             Bringing a file up-to-date
  791. * Conflicts example::           An informative example
  792. * Informing others::            To cooperate you must inform
  793. * Concurrency::                 Simultaneous repository access
  794. * Watches::                     Mechanisms to track who is editing files
  795. * Choosing a model::            Reserved or unreserved checkouts?
  796. File: cvs.info,  Node: File status,  Next: Updating a file,  Up: Multiple developers
  797. File status
  798. ===========
  799.    Based on what operations you have performed on a checked out file,
  800. and what operations others have performed to that file in the
  801. repository, one can classify a file in a number of states.  The states,
  802. as reported by the `status' command, are:
  803. Up-to-date
  804.      The file is identical with the latest revision in the repository
  805.      for the branch in use.
  806. Locally Modified
  807.      You have edited the file, and not yet committed your changes.
  808. Locally Added
  809.      You have added the file with `add', and not yet committed your
  810.      changes.
  811. Locally Removed
  812.      You have removed the file with `remove', and not yet committed
  813.      your changes.
  814. Needs Checkout
  815.      Someone else has committed a newer revision to the repository.
  816.      The name is slightly misleading; you will ordinarily use `update'
  817.      rather than `checkout' to get that newer revision.
  818. Needs Patch
  819.      Like Needs Checkout, but the CVS server will send a patch rather
  820.      than the entire file.  Sending a patch or sending an entire file
  821.      accomplishes the same thing.
  822. Needs Merge
  823.      Someone else has committed a newer revision to the repository, and
  824.      you have also made modifications to the file.
  825. File had conflicts on merge
  826.      This is like Locally Modified, except that a previous `update'
  827.      command gave a conflict.  If you have not already done so, you
  828.      need to resolve the conflict as described in *Note Conflicts
  829.      example::.
  830. Unknown
  831.      CVS doesn't know anything about this file.  For example, you have
  832.      created a new file and have not run `add'.
  833.    To help clarify the file status, `status' also reports the `Working
  834. revision' which is the revision that the file in the working directory
  835. derives from, and the `Repository revision' which is the latest
  836. revision in the repository for the branch in use.
  837.    The options to `status' are listed in *Note Invoking CVS::.  For
  838. information on its `Sticky tag' and `Sticky date' output, see *Note
  839. Sticky tags::.  For information on its `Sticky options' output, see the
  840. `-k' option in *Note update options::.
  841.    You can think of the `status' and `update' commands as somewhat
  842. complementary.  You use `update' to bring your files up to date, and you
  843. can use `status' to give you some idea of what an `update' would do (of
  844. course, the state of the repository might change before you actually run
  845. `update').  In fact, if you want a command to display file status in a
  846. more brief format than is displayed by the `status' command, you can
  847. invoke
  848.      $ cvs -n -q update
  849.    The `-n' option means to not actually do the update, but merely to
  850. display statuses; the `-q' option avoids printing the name of each
  851. directory.  For more information on the `update' command, and these
  852. options, see *Note Invoking CVS::.
  853. File: cvs.info,  Node: Updating a file,  Next: Conflicts example,  Prev: File status,  Up: Multiple developers
  854. Bringing a file up to date
  855. ==========================
  856.    When you want to update or merge a file, use the `update' command.
  857. For files that are not up to date this is roughly equivalent to a
  858. `checkout' command: the newest revision of the file is extracted from
  859. the repository and put in your working copy of the module.
  860.    Your modifications to a file are never lost when you use `update'.
  861. If no newer revision exists, running `update' has no effect.  If you
  862. have edited the file, and a newer revision is available, CVS will merge
  863. all changes into your working copy.
  864.    For instance, imagine that you checked out revision 1.4 and started
  865. editing it.  In the meantime someone else committed revision 1.5, and
  866. shortly after that revision 1.6.  If you run `update' on the file now,
  867. CVS will incorporate all changes between revision 1.4 and 1.6 into your
  868. file.
  869.    If any of the changes between 1.4 and 1.6 were made too close to any
  870. of the changes you have made, an "overlap" occurs.  In such cases a
  871. warning is printed, and the resulting file includes both versions of
  872. the lines that overlap, delimited by special markers.  *Note update::,
  873. for a complete description of the `update' command.
  874. File: cvs.info,  Node: Conflicts example,  Next: Informing others,  Prev: Updating a file,  Up: Multiple developers
  875. Conflicts example
  876. =================
  877.    Suppose revision 1.4 of `driver.c' contains this:
  878.      #include <stdio.h>
  879.      
  880.      void main()
  881.      {
  882.          parse();
  883.          if (nerr == 0)
  884.              gencode();
  885.          else
  886.              fprintf(stderr, "No code generated.\n");
  887.          exit(nerr == 0 ? 0 : 1);
  888.      }
  889. Revision 1.6 of `driver.c' contains this:
  890.      #include <stdio.h>
  891.      
  892.      int main(int argc,
  893.               char **argv)
  894.      {
  895.          parse();
  896.          if (argc != 1)
  897.          {
  898.              fprintf(stderr, "tc: No args expected.\n");
  899.              exit(1);
  900.          }
  901.          if (nerr == 0)
  902.              gencode();
  903.          else
  904.              fprintf(stderr, "No code generated.\n");
  905.          exit(!!nerr);
  906.      }
  907. Your working copy of `driver.c', based on revision 1.4, contains this
  908. before you run `cvs update':
  909.      #include <stdlib.h>
  910.      #include <stdio.h>
  911.      
  912.      void main()
  913.      {
  914.          init_scanner();
  915.          parse();
  916.          if (nerr == 0)
  917.              gencode();
  918.          else
  919.              fprintf(stderr, "No code generated.\n");
  920.          exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
  921.      }
  922. You run `cvs update':
  923.      $ cvs update driver.c
  924.      RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
  925.      retrieving revision 1.4
  926.      retrieving revision 1.6
  927.      Merging differences between 1.4 and 1.6 into driver.c
  928.      rcsmerge warning: overlaps during merge
  929.      cvs update: conflicts found in driver.c
  930.      C driver.c
  931. CVS tells you that there were some conflicts.  Your original working
  932. file is saved unmodified in `.#driver.c.1.4'.  The new version of
  933. `driver.c' contains this:
  934.      #include <stdlib.h>
  935.      #include <stdio.h>
  936.      
  937.      int main(int argc,
  938.               char **argv)
  939.      {
  940.          init_scanner();
  941.          parse();
  942.          if (argc != 1)
  943.          {
  944.              fprintf(stderr, "tc: No args expected.\n");
  945.              exit(1);
  946.          }
  947.          if (nerr == 0)
  948.              gencode();
  949.          else
  950.              fprintf(stderr, "No code generated.\n");
  951.      <<<<<<< driver.c
  952.          exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
  953.      =======
  954.          exit(!!nerr);
  955.      >>>>>>> 1.6
  956.      }
  957. Note how all non-overlapping modifications are incorporated in your
  958. working copy, and that the overlapping section is clearly marked with
  959. `<<<<<<<', `=======' and `>>>>>>>'.
  960.    You resolve the conflict by editing the file, removing the markers
  961. and the erroneous line.  Suppose you end up with this file:
  962.      #include <stdlib.h>
  963.      #include <stdio.h>
  964.      
  965.      int main(int argc,
  966.               char **argv)
  967.      {
  968.          init_scanner();
  969.          parse();
  970.          if (argc != 1)
  971.          {
  972.              fprintf(stderr, "tc: No args expected.\n");
  973.              exit(1);
  974.          }
  975.          if (nerr == 0)
  976.              gencode();
  977.          else
  978.              fprintf(stderr, "No code generated.\n");
  979.          exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
  980.      }
  981. You can now go ahead and commit this as revision 1.7.
  982.      $ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
  983.      Checking in driver.c;
  984.      /usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
  985.      new revision: 1.7; previous revision: 1.6
  986.      done
  987.    For your protection, CVS will refuse to check in a file if a
  988. conflict occurred and you have not resolved the conflict.  Currently to
  989. resolve a conflict, you must change the timestamp on the file.  In
  990. previous versions of CVS, you also needed to insure that the file
  991. contains no conflict markers.  Because your file may legitimately
  992. contain conflict markers (that is, occurrences of `>>>>>>> ' at the
  993. start of a line that don't mark a conflict), the current version of CVS
  994. will print a warning and proceed to check in the file.
  995.    If you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end
  996. for CVS) you can use an Emacs package called emerge to help you resolve
  997. conflicts.  See the documentation for pcl-cvs.
  998.